home *** CD-ROM | disk | FTP | other *** search
- Hi again,
-
- > I've started to look at the c source, it looks quite easy
- > to translate in 68030. And, of course, in 68030, it'll run
- > very FASTER ;-) than in c, coz we can optimize assembler code,
- > not c code... ;-)
-
- I'd be surprised if we could get more than 2-3 times speedup on the
- '030, but I'd very much like that suprise... ;-)
-
- > Before the sprites, I'd like to see the maze running fast and
- > looking pretty good ...
-
- Yes, the maze is of course the more important part, but I worry that
- we'll optimize away the stuff that makes the sprites possible.
- I'll stop thinking about that for the moment, though.
-
- > I think it's not good to start coding details before we know
- > how fast can go the essencial. From what you told me, you've
- > managed to optimize the structure engine, but from how much ?
- > I mean is it big ? ( I mean in memory, of course, to let it
- > enter into the dsp).
-
- The engine itself is not big at all as you can see from the sources.
- I think the sources compile to around 5-10 kbyte m68k object code.
- The data from the WAD I've used was also of quite reasonable size.
-
- The problem is that the engine used a couple of arrays such as
- intersections[50][320], walls[8000] and floorlist[200][40] each of
- which must hold 16000 16 bit integers.
- The arrays were used to store everything that needed to be drawn. The
- actual drawing was then done when everything was ready.
- My optimization consisted of drawing walls, floors and ceilings as
- soon as they were available, which got rid of all three arrays mentioned,
- but introduced a couple of new ones, which fortunately were quite small.
- However, I realized yesterday evening that my optimizations will
- sometimes produce incorrect displays. The original code drew all floors
- before the walls, while I draw a wall(and the closest floor and ceiling)
- at a time. In some cases, such as closed doors, there will be clashes...
- I hope there's a way to handle this, but I've not discovered it yet.
-
- I've heard that SNES DOOM has no floor or ceiling. I'll try that out.
-
- > Actually, I'm looking at the c code, trying to understand the
- > sequences order, to go faster after.
-
- If you have any questions, feel free to ask me. I think I know what's
- going on in most of the code now.
-
- I guess you've seen that the author says that there must be a lot to
- optimize in the actual 3D calculations.
- Have you seen anything that can be done there?
- Do you have any idea why he does the first clipping (to x = z)? If it's
- removed, the most serious display glitches disappear...
-
- > We'll probably have to reduce the size of the picture, to have a
- > correct speed, the player could choose the size of the window...
-
- I'll see how much that improves the speed.
-
- > For the sprites, I've got many documents, I'll look what they say
- > about it. If you want, I can send you a few documents. Bertrand sent
-
- I'd be interested in that.
-
- > Bye for now, tell me when you've got something new.
-
- I'll try to send you a new version of DVIEW shortly. This will include
- all my test stuff, which might be useful.
-
- Regards,
- Johan
-
- --
- Chalmers University | Why are these | e-mail: d8klojo@dtek.chalmers.se
- of Technology | .signatures | rand@cd.chalmers.se
- | so hard to do | www/ftp: rand.thn.htu.se
- Gothenburg, Sweden | well? | (MGIFv5 and QLem)
-
-